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Description 

Field of the Invention 

The present invention generally relates to computer 
systems, and more particularly to a method and system 
for object-oriented compound document processing. 

Background of the Invention 

Document processing has virtually revolutionized 
the way society generates paper. Typical prior art doc- 
ument processing systems run on top of operating sys- 
tems, such as DOS or OS/2. More recently, these doc- 
ument processing systems have been designed to run 
in a Windows environment. Many of these document 
processing systems are commercially available. 

COMPUTER, vol. 21, no. 1, January 1988, LONG 
BEACH US; 'Intermedia: The concept and construction 
of a seamless information environment* from N. YAN- 
KELOVICH ET AL. discloses an apparatus along with 
the method thereof for document processing for use in 
a computer system, the computer having a processor 
a storage, a display under control of the processor and 
at least one document resident in the storage for display 
on the display, said apparatus comprising further. 

document framework means (Intermedia) for 
processing the displayed document and documents 
related to the displayed document, the document 
framework defining a plurality of model classes 
such as the Object class, the Document class, ... 
each of the plurality of model classes defining 
means for referencing data stored in the storage, 
means for creating a container object to hold a plu- 
rality of on objects instantiated from one or more of 
the plurality of model classes and program logic 
means for processing the data and objects held in 
the container object; 

an application for processing the document; 

the program logic means including a means for re- 
ceiving at least one document processing request 
from the application and an object for performing 
the at least one processing request. 

While these document processing systems have 
vastly improved the ability to process documents and 
text, there is great inconsistency among document proc- 
essors with respect to the particular methodologies of 
these processing. The result of these inconsistencies 
creates problems for both application developers and 
users of the applications. 

Application developers must continuously "reinvent 
the wheel" when creating a new document processor. 
While operating systems and interface programs pro- 
vide some tools which may be used, the great majority 



of the design process lor a particular document proces- 
sor is directed toward creating a group of processing 
modules which cooperate to allow the user to process 
documents. Application developers often design 
s processing modules which have already been devel- 
oped by another company. This requires great duplica- 
tion of effort, and requires each developer to deal with 
the details of how to implement various desired func- 
tions. 

10 Application users run into other problems. While 
particular functions may be present in one application, 
they may be lacking in another. Or a function available 
in one application may be slightly varied in another, ei- 
ther in use or in performance. For example, a function 

'5 in application A may require certain user interaction and 
input to activate the function, while a similar function in 
application B may require a slightly varied, or totally dif- 
ferent, user interaction and input. 

20 Summary of the Invention 

It is an object of the present invention as set forth 
in the appended claims to provide a document process- 
ing system in which object-oriented frameworks are uti- 

2S lized to implement particular document processing tech- 
niques, including an object-oriented compound docu- 
ment system. 

These and other objects of the present invention are 
realized by placing the object oriented framework serv- 

30 ices in the operating system of the computer system it- 
self, and not simply to run as some application program 
interface, library, or support coding layer. 

More specifically, the apparatus and method claims 
are directed to the creating of a compound document by 

3S adding one model object to a root model object which 
may be itself considered as a container since each mod- 
el in the hierarchy may be a container for other models 
embedded within. After having created at least one ad- 
ditional model object, processing of the compound doc- 

40 ument is performed by processing of the root model ob- 
ject. 

Brief Description of the Drawings 

4S Figure 1 is a block diagram of a personal computer 
system in accordance with a preferred embodiment 
of the invention; 

Figure 2 is a block diagram of a link, anchors, and 
a model; 

so Figure 3 is a block diagram representing the func- 
tions associated with undo; 

Figure 4 is a diagram demonstrating the system lev- 
el indexing and query processing features of the 
present invention; 
55 Figure 5 is a block diagram of class representation 
in accordance with the present invention; 
Figure 6 is a diagram of a typical document which 
may be made using the present invention; 
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Figure 7 is a diagram showing the hierarchical 
structure of the document shown in Figure 6; 
Figure 8 is a diagram of the general characteristics 
of T Mode I; 

Figure 9 is a diagram of a notification framework 
which could be used with the document framework 
system; 

Figure 10 is a diagram of the relationship defining 
specification classes; 

Figure 11 is a diagram of the relationships associ- 
ated with TModel Command Group; 
Figure 12 is a diagram demonstrating the process- 
ing flow for DoBegin(); 

Figure 13 is a diagram demonstrating the process- 
ing flow for DoRepeat(); 

Figure 1 4 is a diagram showing the relationships es- 
tablished for TModelAnchor; 

Figure 15 shows the relationships established for 
TModelLink; 

Figure 16 is a diagram depicting the processing of 
links; 

Figure 17 shows the processing of Complete Link; 

Figure 1 8 demonstrates the use of annotations and 

scripts being linked to a document; 

Figure 19 shows some of the link properties which 

are available in the system; 

Figure 20 shows the document framework client/ 

server with respect to external documents; and 

Figure 21 is a block diagram showing the method 

and system of the present invention. 

Detailed Description of the invention 

The detailed embodiments of the present invention 
are disclosed herein. It should be understood, however 
that the disclosed embodiments are merely exemplary 
of the invention, which may be embodied in various 
forms. Therefore, the details disclosed herein are not to 
be interpreted as limiting, but merely as the basis for the 
claims and as a basis for teaching one skilled in the art 
how to make and/or use the invention. 

The history of object-oriented programming and the 
developments of frameworks is well-established in the 
literature. C++ and Smalltalk have been well-document- 
ed and will not be detailed here. Similarly characteris- 
tics of objects, such as encapsulation, polymorphism 
and inheritance have been discussed at length in the 
literature and patents. For an excellent survey of object 
oriented systems, the reader is referred to "Object Ori- 
ented Design With Applications" by Grady Booch, ISBN 
0-8053-0091-0(1991). 

While many object oriented systems are designed 
to operate on top of a basic operating system performing 
rudimentary input and output, the present system is 
used to provide system level support for particular fea- 
tures. 

The invention is preferably practiced in the context 
of an operating system resident on a personal computer 



such as the IBM ® PS/2 ® or Apple ® Macintosh ® com- 
puter. A representative hardware environment is depict- 
ed in Figure 1 , which illustrates a typical hardware con- 
figuration of a computer in accordance with the subject 

5 invention having a central processing unit 10, such as 
a conventional microprocessor, and a number of other 
units interconnected via a system bus 1 2. The computer 
shown in Figure 1 includes a Read Only Memory (ROM) 
16, a Random Access Memory (RAM) 14, an I/O adapt - 

io er 18 for connecting peripheral devices such as disk 
units 20 and other I/O peripherals represented by 21 to 
the system bus 12, a. user interface adapter 22 for con- 
necting a keyboard 24, a mouse 32, a speaker 28, a 
microphone 26, and/or other user interlace devices 

is such as a touch screen device (not shown) to the bus 
12, a communication adapter 34 for connecting the 
workstation to a data processing network represented 
by 23. A display adapter 36 for connecting the bus to a 
display device 38. The workstation has resident thereon 

20 an operating system such as the Apple System 7 ® op- . 
erating system. 

The main goal of the document framework dis- 
closed herein is to raise the base level of applications 
by enabling several new features at the system level. In 

25 addition, the lack of system support for these features 
limits their implementation. For example, there are ap- 
plications that allow users to annotate static represen- 
tations (pictures) of any document, but not the "live" doc- 
ument itself. The content-based retrieval applications 

30 have trouble accessing the contents of document be- 
cause each application has a custom file format. Also, 
once the application finds a document, it is difficult to do 
anything with it. There's no system-level support for 
opening the document, for example. The document 

35 framework also includes a number of higher-level capa- 
bilities, such as annotation support, which are built upon 
these basic services. To the extent possible, the docu- 
ment framework does not specify any policy or user in- 
terface decisions. These details will be provided by the 

40 particular applications using the document framework. 

Collaboration 

Screen sharing is one popular type of collaboration 
45 on the Macintosh, because it is relatively easy to imple- 
ment and can be put to many uses. Its main disadvan- 
tages are that some applications draw directly to the 
screen (complicating the implementation) and the large 
bandwidth required to transmit all drawing operations 
50 from one machine to another. Also, it is very restrictive, 
since it is based on all collaborators viewing the docu- 
ment in exactly the same way. 

Screen sharing is one kind of simultaneous, real- 
time collaboration. The document framework provides 
55 support for a different kind of simultaneous, real-time 
collaboration. This operates at the level of changes to 
the document, rather than changes to the screen, which 
will be more efficient because the amount of data need- 
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ed to specify a document change is usually less than 
the amount needed to update the screen. 

It is also useful to have asynchronous (i.e., non real- 
time) collaboration. One form of this is the ability to an- 
notate a document. The document framework provides 
low-level support for annotations through its model and 
linking mechanisms (described below). 

Hypermedia Linking 

Figure 2 shows an illustration of the present inven- 
tion. The blocks represent both the apparatus and the 
methods involved in the system. As shown in Figure 2, 
in the document framework, a link 204 is a bi-directional 
connection between anchors 202 and 206. The mean- 
ing of an anchor is application-specific, but in most cas- 
es an anchor identifies a sticky selection. An anchor is 
sticky in that it always refers to the same data regardless 
of the user's editing changes. For example, if the anchor 
refers to a word within a text block, it always refers to 
that word, even il the text around it changes. Anchors 
are associated with a particular encapsulated block of 
data (called a model) 200. Each kind of data in the sys- 
tem is represented as a specific subclass of TModel. 
The abstract base class, TModel, defines generic pro- 
tocol to enable other models to embed, display,, and ma- 
nipulate this data as a "black box." For example, an ap- 
plication can ask the model to create a presentation 
(view) of the data. These presentations range from a 
small thumbnail to a fully editable presentation. There 
is also protocol for accessing the anchors associated 
with the model's data and for accessing other models 
embedded within it. A document's data is represented 
by a hierarchy o1 models, with a single model at the root 
called the "root model." 

Once the user creates a link, the user can operate 
upon it. First, the user can navigate from one end of the 
link to the other. In general, this involves opening the 
document containing the target anchor scrolling the an- 
chor into view, and highlighting the corresponding se- 
lection. Applications can change this behavior; for ex- 
ample, navigating to a sound document may simply play 
the sound without opening the document. It is also pos- 
sible to transfer data across the link in either direction. 
The semantics of transferring data is (roughly) equiva- 
lent to copying the source data, navigating to the desti- 
nation anchor, and replacing the existing data with the 
transferred data. It makes no difference to the document 
framework whether the data is pushed or pulled through 
the link (i.e., whether the source or destination initiates 
the transfer). 

The document framework also allows one applica- 
tion to send an arbitrary command across a link. This 
will allow cooperating applications to implement custom 
features using the same basic linking mechanism. The 
straightforward use for the document framework's low- 
level linking mechanism is to allow users to create links 
between documents, navigate those links, transfer data 



across them, etc. This isn't the only use for links, how- 
ever. Links will also be used to implement other appli- 
cation features. In these features, the fact that links are 
created and manipulated will be transparent to the user. 

5 For example, the system-wide annotation facility 

uses links to associate an annotation with the part of the 
base document to which it refers. The system can posi- 
tion a posted note icon (representing the annotation) 
near the part of the document to which it refers. In ad- 

10 dition, if the annotation contains a suggested change to 
the document, it is possible for the author to "accept" 
the suggestion and have the system automatically 
transfer data across the link from the annotation to the 
document. 

is Another user-transparent use of linking would be to 
implement a function performed by the Edition Manager 
of System 7. The user could publish part of a drawing 
and subscribe to that data in a word processing docu- 
ment. Internally, the system would create a link between 
20 the documents, and perhaps attach an attribute to the 
link that indicates the nature of the link (e.g., which end 
is the source of the data). The existence of the link may 
be transparent to the user. 

Changes to the drawing are sent across the link to 
25 the word processing document. The document frame- 
work does not restrict which end of the link initiates this 
transfer. The user can navigate from the destination to 
the source of the data (from the word processing docu- 
ment to the drawing document). The document frame- 
30 work also supports navigating in the opposite direction 
because all links are bi-directional. 

The document framework's models also improve 
the way simple copy and paste works. On the Macin- 
tosh, an application handles a paste command in three 
3S different ways, depending on the type of the data model 
in the Clipboard. (1 ) The document can fully understand 
the pasted data, and the data becomes a first-class part 
of the document. (2) The receiving document can dis- 
play the incoming data but not manipulate it. A typical 
40 example is a picture pasted into a text document. In this 
case, the incoming data can be displayed but not edited. 
(3) The incoming data type isn't understood by the re- 
ceiving document. Here, the paste command can't be 
completed, and should be disabled. 
45 |f the data cant be absorbed, then it can be embed- 
ded in the receiving document in the form of a model. 
Because models support generic protocol for creating 
editable presentations of the data, embedded data is not 
"dead* as is true on the Macintosh. Instead, the user can 
so open up an embedded model and view or edit the data 
it contains. This capability is similar to that provided by 
HP's New Wave system or Microsoft's OLE specifica- 
tion. An important difference is that the objectoriented 
document framework makes it easier for a developer to 
55 implement a new data type. Finally, if an application sup- 
ports embedded models, then it can paste every type of 
data. The paste command would never be disabled as 
long as the Clipboard wasn't empty. 
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Eternal Undo 

In most Macintosh applications, the undo command 
is precious, since only the last change can be undone. 
The document framework uses the same kind of com- 
mand objects as MacApp, but saves as many command 
objects as possible. 

This decision has several benefits. First, it isn't as 
important to be choosy about what commands are un- 
doable. For example, in existing Macintosh applications, 
changes to the selection are not undoable, even though 
some selections can be difficult to create. In a drawing 
program, the user can spend much time selecting the 
right combination of shapes and lose everything with an 
extra click. If the system supports only one level of undo, 
then it is unwise to save a selection change if it means 
forgetting about the last Cut command, for example. 
With multiple levels of undo, it is feasible to save selec- 
tion changes. 

Another benefit of using command objects is in- 
creased reliability. If every command is saved, then it is 
possible to replay those commands in the event of an 
application or system crash. The document framework 
uses concurrency control and recovery classes to save 
command objects in a robust manner. In the event of a 
crash, the user should not lose more than the last couple 
of commands. With multi-level undo comes the added 
burden of providing a good way to visualize and navi- 
gate the list of commands. This is especially true if se- 
lection changes are included, because it will be easy for 
the user to create hundreds of commands. 

Figure 3 shows The document framework linear list 
300 of command objects 302, which can be likened to 
a stack. There are many other ways in which the undo 
processing could be carried out. This means that undo 
306 returns the document to a previous state. It is also 
contemplated that the user can selectively undo com- 
mands 304 (i.e., undo a Cut command but keep all sub- 
sequent commands intact). It should be remembered 
that commands are dependent on one another. A com- 
mand that copies a shape is dependent on the com- 
mand that first created the shape. These dependencies 
would complicate the user interface to undo, as well as 
the underlying implementation. 

A good solution is to integrate the undo and script- 
ing mechanisms, for example to automatically create a 
script of everything that is done. The user can then edit 
the script to remove arbitrary commands, rearrange 
commands, etc. and execute the script. This gives users 
the maximum flexibility and control. 

Content-based Retrieval 

Increasingly, users have more and more informa- 
tion available on their computers. Local hard disks are 
getting larger, and there are many CD-ROMs available 
that contain hundreds of megabytes of data. It is impos- 
sible to browse through this data without some assist- 



ance from the system. In the Macintosh, the standard 
tool used to be Find File : which located documents 
based on their names. System 7 provides a Find com- 
mand that is integrated within the Finder. Third party de- 
5 velopers also provide tools that go beyond Find File and 
search for documents based on their content, but which 
aren't well-integrated with the system. 

It is important that these retrieval tools be integrated 
into the system. There's little point in locating docu- 
ments if the user can't do anything with them. The third 
party content-based retrieval tools on the Macintosh get 
no system support in examining the contents of the doc- 
ument, or even opening the document with the appro- 
priate application. 

Figure 4 shows the generic retrieval framework of 
The document framework from a source of information 
400. The framework handles both indexing 402 and 
queries 404. Although many future operating systems 
will deliver with a default indexing and query package, 
users will still want the ability to plug in new search - 
packages into the basic framework. The point of design- 
ing a framework is so that the background indexing 
mechanism and query user interface are the same re- 
gardless of the underlying retrieval technology. 

The framework will provide for automatic, back- 
ground indexing of documents when they are added to 
a volume or changed. A retrieval system is worthless if 
only some of the documents are indexed, and it is un- 
reasonable to place this burden on the user. A generic 
query front-end will allow a user to install a new retrieval 
engine and not have to learn a new front-end. 

Classes, The Developer's View 

This section contains class and member function 
descriptions. Certain conventions are followed. All 
classes have virtual destructors. If the destructor does 
anything more than release storage, it is discussed; oth- 
erwise, nothing is said. Methods inherited from MCol- 
lectible (Figure 5, element 500), such as streaming op- 
erators, are not discussed here. Many of the classes 
have getters and setters which simply do field accesses. 

Object Surrogates 

Several objects in the document framework provide 
object surrogates, which act as compact, address space 
independent references to the real object. This use of 
surrogates can be described as "Explicit master and sur- 
rogates". In a few cases, surrogates and real objects 
can be used interchangeably, but in most cases the sur- 
rogate serves as a "key" for finding the real object. In all 
cases the relationship between the surrogate and real 
object is defined by a common abstract base class. The 
abstract base class provides the address space inde- 
pendent identification for the object and implements the 
protocol for comparison between objects (IsEqual). This 
allows a surrogate to be compared directly against a real 
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object and used as a key into a set of real objects for 
lookup. Surrogate objects provide a constructor which 
will create a surrogate from a real object allowing easy 
creation of surrogates. 

For example, it is necessary for TModelSelections 
to identify TModel objects in an address space inde- 
pendent manner to allow commands to access data in 
multiple collaborator's address spaces. TModel and 
TModelSurrogate both derive from the common base 
class TAbstractModel. TAbstractModel provides the ad- 
dress space independent identification of the object and 
implements the protocol for comparison between ob- 
jects. TModel provides static member functions for look- 
ing-up the real model from a surrogate. When a selec- 
tion is streamed, it streams only a surrogate for the mod- 
el to which it refers. When the command attempts to ac- 
cess the data through the selection, the real model is 
looked up using the surrogate to provide the command 
access to the real model data. 

Data Representation 

Figure 5 shows Representation classes. The ab- 
stract base class that encapsulates the data for a par- 
ticular data type is TModel 506. Derived classes of 
TModel 506 are the containers for "document" data. 
They provide type specific protocol for accessing and 
modifying the data contained in the model. They must 
also override generic protocol that supports embedding 
other models and for being embedded in other models. 
This mostly involves overriding protocol for creating se- 
lections and user interfaces on the data. 

TModel objects 506 also provide notification of 
changes to the contained data to interested objects (typ- 
ically presentations). Notification could be provided us- 
ing a standard notification facility of the underlying sys- 
tem, if the system has such notification available. See 
the "Data Presentation" section for details on model no- 
tification. 

The class TModelSurrogate 504 provides a light- 
weight stand-in or "name" for an actual TModel 506. It 
does not actually contain the data, only the real model 
does that, but it does provide protocol for a subset of the 
behavior supported by TModel. Specifically, the behav- 
ior necessary to appear and operate within the "Work- 
space". The behavior which TModelSurrogate 506 and 
TModel 506 share is defined by their common base 
class TAbstractModel 502. 

Compound Document Structure 

A document, such as shown by element 600 in Fig- 
ure 6, can contain many models which can be of many 
different classes. The basic structure of the document 
is a hierarchy of models which reflects the containership 
hierarchy of the document. A single model exists at the 
root of the hierarchy and is referred to as the "root mod- 
el." Each model in the hierarchy may be a container for 



other models embedded within. A container model re- 
fers to its embedded models with model surrogates. 
C++ pointers must not be used because the embedded 
models may be filed using separate contexts from the 

5 container and are not necessarily in memory with the 
container. By accessing a model through a surrogate it 
will automatically be filed in if not already in memory. 
Optionally, the embedded document can be a directed 
acyclic graph. Multi-column text can be implemented 

io this way; the individual columns of text were going to be 
models that all embedded a single shared text -flow 
model. Also, each model can be locked independently, 
providing more potential concurrency at the cost o1 more 
complexity. 

*5 "The Standard Example" shown in Figure 6 illus- 
trates a specific model hierarchy. Each model in the hi- 
erarchy which has a presentation included in the docu- 
ment has an associated TUser Interface (which is itself 
a model containing user interface objects). The TUser- 
20 Interface for a particular model is managed by that mod- 
el and is accessible only through that model. Models 
which are not viewed directly, but rather through another 
"presentation model", would not have an associated TU- 
serlnterface. For example, a TTableModel which was 
25 viewed only through a TGraphModel as a scatter plot, 
would not have a TUserlnterlace, while the TGraphMod- 
el would, since it is providing a presentation to the user. 

Figure 7 demonstrates the hierarchical nature of the 
document of Figure 6. In particular, sections 0-5 repre- 
ss sent various types of information which may be embed- 
ded within other types of information. For example, Sec- 
tion 1 is the Taligent® text, which is embedded within 
the Taligent® logo, which is shown by Section 2. The 
lower right corner of Figure 7 shows the hierarchical 
35 structure of the document of Figure 6. 

Data Types 

The compound document architecture supports the 
40 seamlesss integration of many data types. These may 
include, but are not limited to, voice, graphics, bit- 
mapped images, pictures, tables, video, text, financial 
data, files, and program components. Virtually any vis- 
ible or audible data type may be incorporated into the 
45 compound document in a seamless manner. 

Managing Embedded Models 

It is up to a derived class of TModel to provide an 
so implementation to manage any embedded models it 
contains. TModel does not provide an implementation 
for this because it is extremely data dependent as to how 
the embedded models fit into the container's data struc- 
tures. The document framework does include a TCon- 
55 tainerModel that provides an implementation for simplis- 
tic embedding in which the embedded model presenta- 
tions simply "float" over the containing presentation. 



6 



11 



EP 0 728 



338 B1 



12 



Copying, Streaming and Filing 

Models which are embedded in another model are 
considered part of the containing model's data for pur- 
poses ot copying and streaming. When a mode! is cop- 
ied, streamed or filed, the embedded models it contains 
must be handled appropriately. TModel provides default 
implementations which make the handling of embedded 
models straightforward for these cases. 

Streaming 

The standard streaming operators (operator^ and 
operator«=) provided by TModel stream all data owned 
by TModel, including anchors and links. These stream- 
ing operators also take care of streaming any embedded 
models contained within the model being streamed. A 
derived class overrides these operators to stream its 
own data. If the model contains embedded models, only 
the surrogates for those models need to be streamed. 
The inherited streaming operators take care of stream- 
ing the real embedded models. For models which file 
their data by streaming, these methods may be identical 
to the filing methods. In such cases, it is usually desir- 
able to create private helper functions which can be 
called by both the streaming operators and the filing 
methods. 

Copying 

When copying an entire model, or copying selected 
data from the model, the embedded models must be 
copied by the container. This is easily accomplished by 
using the "CopyModer method of the TModelSurrogate 
for the embedded model. This method copies the sur- 
rogate and real model providing a new consistent mod- 
el/surrogate pair. 

Fifing 

When filing a model, its embedded models must al- 
so be filed. The embedded models must be filed inde- 
pendently from the container to allow customization of 
storage for the embedded models. When a model is 
asked to file its data in FileOutData(), it only files surro- 
gates for any embedded models which it contains. The 
embedded models are filed automatically by the docu- 
ment framework. The filed surrogates are read back in 
FilelnData(), and may be used to access the real model. 
All dirty models in a document are always filed out to- 
gether. This simplifies the handling of the Roll-Forward 
log. Models are individually filed in when requested from 
model surrogates. 

When a new model is added to the document it must 
be given the opportunity to create a new store for itself. 
The method CreateModelStoreO is called passing in the 
document root model's store. If this store is acceptable 
to the model no new store is created. Otherwise, the em- 



bedded model will create a new store to use for its stor- 
age requirements. The actual creation of the store is 
done in a lazy fashion, so that models created in mem- 
ory for temporary use that do not require a store will not 

5 create one. 

When a model is removed from the document it 
must be deleted from both memory and storage. Delet- 
ing a model will delete the model from memory and from 
store. If the model is to be deleted from memory only 

10 the method TModel: : Delete From Memo ryOnly() can be 
used rather than calling delete. 

Concurrency Control 

15 a single monitor protects all the data in a document. 
This monitor is entered by creating a TModelEntry ob- 
ject on the stack. 

Attributes 

20 

TModel provides an extensible interface and imple- 
mentation for attaching attributes to models. The at- 
tributes are inheritable via the model hierarchy. That is, 
a model can inherit attributes from its ancestors. TModel 

25 provides support for looking up attributes on a specific 
selection in a model and for including or excluding an- 
cestors from the lookup. Attributes are maintained in a 
simple attribute group and provides its own inheritance 
support rather than using the TlnheritableAttribute- 

30 Group because all models in the hierarchy are not nec- 
essarily in memory at one time, and this behavior is not 
supported by TlnheritableAttributeGroup. 

TAbstractModel 

35 

TAbstractModel is the base class for TModel and 
TModelSurrogate. It provides the protocol which is com- 
mon to both of these classes and provides the common 
base class between the real and surrogate classes as 

40 described in the "Object Surrogates 0 section of this doc- 
ument. TAbstractModel is an abstract base class. It is 
only instantiated as part of a derived class. The following 
methods provide access to the model's storage: 1 ) Set- 
ModelStoreReference, 2) AdoptModelStoreReference, 

45 3) CopyModelStoreReference, 4) GetModel Store. 
TModel and TModelSurrogate are the only classes 
which derive from TAbstractModel. TAbstractModel is 
abstract and therefore is always created and deleted as 
part of a derived class. Any data created by TAbstract- 

50 Model as part of its implementation is managed by the 
class. 

TModelSurrogate 

55 TModel Surrogate is a lightweight "stand-in" or 
"name" for a TModel which provides full addressability 
of the real model in storage. Any number of TModelSur- 
rogates may exist for a single TModel. TModelSurrogate 
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also serves as the address-space independent specifier 
of a TModel for purposes of collaboration. TModel Sur- 
rogate is a concrete class and may be freely instantiated 
and destroyed. TModelSurrogate provides concrete im- 
plementations for all of the abstract functions of TAb- 
stractModel. The following methods support access to 
and management of the real model represented by this 
surrogate: 1 ) GetModel, 2) CopyModel, 3) DeleteModel. 
The following methods provide access to the model's 
anchors: 1 ) Copy Anchor, 2) CreateAnchorlterator. The 
following methods support presentation of the model 
represented by the surrogate. These presentations are 
static. They do not reflect changes to the content of the 
real model. 1) Createlcon, 2) CreateThumbnail. 

TModel 

Figure 8 demonstrates TModel 800, which is the 
container for all document data 802, including anchors 
and links and serves as the unit of data exchange for 
cut/copy/paste. It provides protocol that supports em- 
bedding 804 the data in other alien data models and/or 
embedding alien data models within. The base class 
TModel provides the implementation for managing a 
model's anchors 806 and links 808. Subclasses provide 
the protocol and implementation for accessing and man- 
aging the type-specific data. Additionally, the subclass 
must implement the base class protocol for creating a 
user interface, selections and accessing embedded 
models. TModel derives from MDelegatingNotifier and 
therefore can be connected to for notification on chang- 
es to the model's data 810. All models in a TDocument 
share the TModel class notifier and delegate all calls to 
that notifier. Several member functions support man- 
agement of a model's user interface model. Subclasses 
must override CreateUserlnterface to create the appro- 
priate user interface for this model. In the future the 
choice of interface could be determined from a user pref- 
erence. The member functions are: 1 ) CreateUserlnter- 
face, 2) AdoptUserlnterface, 3) GetUserlnterface, 4) 
GetUserlnterfaceSurrogate. Numerous member func- 
tions also support accessing and modifying a model's 
set of anchors and links, as well as accessing and mod- 
ifying attributes associated with the models. 

DATA PRESENTATION 

Notification Classes 

Data contained in a TModel is of little interest unless 
it can by viewed and/or modified by the user. Although 
the document framework does not directly provide the 
classes necessary to implement data presentations, the 
document framework does provide support for manag- 
ing presentations on models. This section deals prima- 
rily with notification, since this is the extent of presenta- 
tion support provided directly by the document frame- 
work. For example, all other presentation support could 



be provided by an object-oriented User Interface Tool- 
box. 

User Interface Management 

5 

The document framework provides support for 
managing a model's user interface. Protocol is provided 
by TModel for creating, storing and retrieving a model's 
associated user interface. A client of TModel can ask 
10 the model for its user interface. In turn the client can ask 
the user interface lor an Embedded, or Window presen- 
tation. The document framework provides no support for 
the contents of a user interface, only for managing its 
access and storage. See the section, "Data Represen- 
ts tation" for a description of this facility of TModel. 

Notification 

Figure 9 sets out the notification system for the doc- 

20 ument framework. The document framework provides 
change notification to clients of TModels (clients are typ- 
ically presentation views) on all changes made to the 
data contained in a model. A presentation can connect 
to a model for notification on specific changes, or all 

25 changes, to a model's data. By performing the proper 
updates to the presentation when the notifications are 
received, the presentation remains synchronized with 
the underlying data. TModel provides notifications for 
changes to the data it manages, specifically anchors & 

30 links, via TLinkNotification 906 and TAnchorNotification 
908, and selections, via TSelectionNotification 902. 
Standard notifications are also provided for Cut/Copy/ 
Paste operations (not explicitly shown). Other notifica- 
tions relative to the document framework are also con- 

3S templated. For example, TDualSelection Notification 
provides notification of dual selections. It is the respon- 
sibility of a subclass of TModel to provide notifications 
specific to that model's data. The notifications must be 
sufficient for presentations to remain consistent with the 

40 underlying data. 

Data Specification 

In the document framework the class that supports 
45 the specification of document data is TModelSelection. 
It is important to note that model selections are truly 
specifications of the selected data, and do not actually 
contain the data. Furthermore, the specification must 
identify the data in an address independent way, so that 
so selections can be applied in multiple collaborator's ad- 
dress spaces. The document framework manages data 
at the granularity of whole models and provides default 
functionality that operates on whole models. TModelSe- 
lection is no exception. TModelSelection provides pro- 
55 tocol and implementation for specifying the selected 
model. Typically an implementation of a derived class 
of TModel will provide a corresponding derived class of 
TModelSelection which supports specification of the da- 
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ta contained within the model at a finer grain than the 
whole model. This allows commands to be applied to a 
subset of the data in a model, rather than the entire mod- 
el. 

Data Exchange 

Figure 1 0 shows the specification classes, which in- 
clude TModelSelection 1002 and MColledtible 1000. 
TModelSelection 1002 defines protocol for the ex- 
change of data between selection objects. This protocol 
is used by a number of standard commands provided 
by the document framework. These include, Cut, Copy, 
Paste, Push and Pull commands. TModelSelection 
1 002 provides the protocol for negotiating data types for 
exchange between selections. A source selection pro- 
duces a list of model types in which it can produce the 
selected data. The destination selection chooses the 
type of model in which it prefers to receive the data and 
how it will receive it (absorb or embed). After a type has 
been selected via the type negotiation process, the 
source selection is asked for a copy of the data in the 
chosen type by calling CopyData. The model returned 
is then passed to the destination selection in AbsorbDa- 
ta or EmbedData depending on how the selection indi- 
cated it would receive the data in the type negotiation. 
The negotiation may occur across document teams 
when exchanging data between anchors. In this case 
services of TRemoteDocument are used to access re- 
mote information. The entire exchange process de- 
scribed above is typically carried out by a command ob- 
ject such as TPasteCommandorTPushDataCommand. 



TModelSelection 

The class, TModelSelection 1002, provides most of 
the protocol that document selections and anchors (per- 
sistent selections) are expected to implement. It serves 
as the base class for all selection objects. TModelSe- 
lection objects contain the protocol for exchanging data 
between selections using cut, copy, and paste or using 
push/pull (on anchors). This includes the protocol for 
type negotiation (what types can I publish this data in, 
what types can I accept data in) and the protocol for ac- 
cepting or publishing data in a specified type. 

Member functions CreatePreferredTypeList, 
ChoosePreferredType, and GetTypeAcceptKind are in- 
herited from MTypeNegotiator and support type negoti- 
ation for exchange of data between selections. Member 
functions are also provided for supporting adding, re- 
moving, and creating anchors to the selection. Member 
functions are also provided to support the exchange of 
their associated model's specific type of data. The sub- 
class does not need to concern itself with the copying 
of anchors and links. This is handled by TModelSelec- 
tion automatically. Member functions are also provided 
to override if anchors must be adjusted when imported 



or export (e.g. anchors in text must be adjusted to be 
relative to the exported data when exported and to the 
containing context when imported). 

Data Modification 

Figure 11 shows the basic relationships necessary 
for carrying out data modification. TModelCommand- 
Group 1104, TModelCommand 1102, and TCommand 
1100 each cooperate to provide the necessary modifi- 
cations required within the system. 

Modification Classes 

In the document framework the abstract base class 
that represents a command made by the user is TMod- 
elCommand 1102. Subclasses of TModelCommand 
1102 encapsulate the semantics of a user action and 
can change model based on the user action. Command 
objects can be "done", "undone", and "redone", and are 
typically independent of the user interface technique 
used to create them. 

TModelCommand 1102 

TModelCommand 1102 is a derived class of the 
TCommand 1100 class. TModelCommand 1102 objects 
encapsulate a user action which changes the model. 
TModelCommands have protocol for: Doing, undoing 
and redoing the change to the model, Identifying the col- 
laborator who issued the command, and Doing the 
change incrementally, as when dragging or typing. 

TModelCommand objects 1102 typically operate on 
a selection which may be part of the command object 
or more typically the current document selection. The 
base class, TModelCommand 1102, provides the proto- 
col that all model command objects respond to. Sub- 
classes override the "HandleXXX" methods to provide 
specific behavior. 

Some TModelCommands are intended to be exe- 
cuted incrementally. These commands are used to allow 
the user to incrementally modify a model. These com- 
mands are called repeating commands. One example 
of a repeating command is a shape dragging command 
for a drawing program. Even though a tracking com- 
mand might force the model to go through many inter- 
mediate states, it counts as a single command. The 
means that the entire effect of the command is undone 
and redone as a single atomic action. 

The document framework uses the concept of a 
command object in its framework for Undo. Command 
objects are also central to the collaboration features of 
the document framework. 

Model Based Tracking Details 

Figure 12 shows a diagrammatic representation of 
a possible processing flow for carrying out a part of the 
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tracking operations in the document framework. As in- 
dicated by 1200, when the tracker calls DoBegin() the 
command argument is flattened 1202 and sent to the 
collaboration server, at 1204. From there it is flattened 
again and sent to each of the collaborators. At each col- s 
laborator the command's HandleDoBeginQ method is 
executed, as indicated at 1 206. 

Figure 13 shows a diagrammatic representation of 
a possible processing flow for carrying out another part 
of the tracking operations in the document framework. io 
When the tracker calls DoRepeat(), as indicated by 
1300, the command argument is asked to stream out 
the delta information 1 302. The command delta is sent 
to the collaboration server, at 1 304. From there the delta 
is sent to each of the collaborators. At each collaborator is 
the delta is streamed into the local copy of the com- 
mand, as indicated by 1306. Then the command's Han- 
dleDoRepeat() method is executed. 

When the tracker calls DoEnd() similar operations 
as those shown with respect to Figure 1 3 are performed. 20 
The command argument is asked to stream out the delta 
information. The command delta is sent to the collabo- 
ration server. From there the delta is sent to each of the 
collaborators. At each collaborator the delta is streamed 
into the local copy of the command. Then the com- 25 
mand's HandleDoEnd() method is executed. There are 
two ways an incremental command can finish its extend- 
ed Do phase. The standard way is for DoEnd() to be 
called. The other way is for the collaborator who is doing 
the tracking to unexpectedly leave the collaboration. In 30 
that case the command on the collaboration server has 
it's HandleCollaboratorDied() method called. After the 
extended Do phase is finished, the command is expect- 
ed to be in the same state as if it's HandleDo() method 
was called. 35 
TModelCommandGroup: TModelCommandGroup is a 
subclass for 

TModelCommand which allows complex commands to 
be easily built from several simple commands. TModel- 
CommandGroup delegates most methods (e.g. Handle- 40 
Do) to each of the commands in the group. The com- 
mands are not truly serialized, in that HandleLocalDo is 
called for all commands, and then HandleDo is called 
for all commands. If the HandleLocalDo of a command 
relies on state set by an earlier command's HandleDo, 45 
this will not work. 

The following member functions support the manage- 
ment of commands contained in the command group: 
AdoptFirst, AdoptLast, Orphan, OrphanAII. 

50 

Standard Commands 

The following commands are all standard com- 
mands provided by the document framework. 

55 

TSelectCommand: The TSelectCommand should 
be issued when changing selections. TSelectCom- 
mand is an incremental command supporting direct 



manipulation for selection This command sets the 
selection for the collaboration initiating the com- 
mand and does not affect other collaborator's se- 
lections. 

TCutCommand: The TCutCommand has the local 
effect of cutting the current selection out of the doc- 
ument. It has the global effect of adding something 
to the clipboard. The local effect is accomplished by 
subclassing TReplaceSelection command. 
TCopyCommand: The TCopyCommand has no lo- 
cal effect. It has the global effect of putting some- 
thing on the clipboard. 

TPasteCommand; The TPasteCommand replaces 
the current selection with the data on the clipboard. 
This is accomplished by subclassing TReplaceSe- 
lection command. 

TReplaceSelectionCommand: The TReplaceSe- 
lectionCommand replaces the data specified by a 
selection or anchor with data encapsulated in the 
command object. The command object contains a 
TModei which is used to replace the selection's da- 
ta. You will typically never create a TReplaceSelec- 
tionCommand yourself, the document framework 
use this command object in cut, paste, push, pull, 
etc. 

TNewAnchorCommand: The TNewAnchorCom- 
mand is issued whenever a new anchor is created. 
A TStartLinkCommand acts as a TNewAnchor- 
Command after the global effect of TStartLink is 
done. 

TNewLinkCommand: The TNewLinkCommand is 
issued whenever a new link is created. A TCom- 
pleteLinkCommand subclasses TModelCommand- 
Group with TNewLinkCommands embedded in it. 
TStartLinkCommand: The TStartLinkCommand 
has the global effect of putting a new anchor on the 
"link board" and the local effect of adding a new an- 
chor to the document. The local effect is accom- 
plished by subclassing TNewAnchorCommand. 
TCompleteLinkCommand: The TCompleteLink- 
Command has to do a lot of work. It has the (possi- 
bly) non-local effect of posting a new link command 
to another document (the document which issued 
the start link command). It has the local effect of 
adding an anchor and a link to the current docu- 
ment. This is accomplished using the appropriate 
command objects (TNewAnchor and TNewLink) in 
its implementation. 

TPushDataCommand: The TPushDataCommand 
has the (possibly) non-local effect of posting a 
TPushedData command to the destination anchor. 
All type negotiation is handled via the selection pro- 
tocol. 

TPullDataCommand: The TPullDataCommand 
command could be called the pull command. It re- 
trieves data from an anchor at the other end of a link. 
TFollowCommand: The TFollowCommand will 
"follow" a link. This involves posting a TFollowed- 
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Command to the document containing the other 
side of the link. 

TFollowedCommand: The TFollowedCommand 
is posted to the document containing the destina- 
tion anchor in a link. The "there" side of the TMod- s 
elLink embedded in the TFollowedCommand is the 
destination anchor. The Follow method of the des- 
tination anchor will be called. Override this method 
to implement the proper follow behavior (typically 
scroll the anchor and its selection into view). 

Anchors & Links 

Figure 14 demonstrates the relationships between 
MCollectible 1400, M Abstract Modeler 1102, TModelSe- 
lection 1404, TModelAnchorSurrogate 1106, and 
TModelAnchor 1408. 

Figure 15 demonstrates the relationships among 
MCollectible 1500 : TAbstractModelLink 1502, TModel- 
LinkSurrogate 1504, and TModelLink 1506. 

Anchor and Link Classes 

Anchors are typically "sticky" document selections. 
Sticky means that the data selected by the anchor is 
constant across editing changes in a model. 

Links are connections between two anchors. Oper- 
ations on links include creating them, removing them, 
"following" them, pushing data from one sticky selection 
to the other, or pulling data. To create a link between two 
anchors, the user must specify the anchors. The situa- 
tion is similar to copying and pasting data (the user 
needs to specify a source and destination), so one way 
to do this is to maintain a kind of "linkboard," analogous 
to the clipboard. 

Figure 16, between 1600 and 1606, shows the Start 
Link command processing flow The Start Link com- 
mand would create an anchor out of the current selec- 
tion at 1602 and place the anchor on the linkboard at 
1604. 

Figure 17, between 1700 and 1710, shows process- 
ing flow of The Complete Link command. The Complete 
Link Command would also create an anchor at 1702, 
and then create a link between the new anchor and the 
one on the linkboard at 1704. It is possible to choose 
Complete Link at 1706 several times, in order to create 
several links that share a common anchor, as indicated 
by the processing flow 1708. 

Figure 18 demonstrates links in a document 1800 
which have been created by an application programmat- 
ically. We expect that most of the "interesting" uses of 
linking will fall into this category. For example : annota- 
tions 1802 can be attached to the affected parts of the 
document with links 1804. Scripts 1806 can also refer 
to parts of a document with links 1 808. It should be noted 
that the links of Figure 18 are merely representative of 
software structures and are not intended to convey any 
particular visual characteristics of links, scripts, annota- 



tions, or the document portions linked to. There is only 
one kind of link in the document framework. It is bi-di- 
rectional, as indicated by the bidirectional links 1804 and 
1808, and supports both navigation (finding the other 
end of the link) and data transfer. 

Figure 1 9 demonstrates some of the characteristics 
of links. Links also have properties 1900, which appli- 
cations can use to classify 1 902 links and to restrict 1 904 
how links are used. For example, there could be prop- 
erties that specify what the user 1 908 can do 1 906- with 
a link. It might be desirable to allow certain users only 
to pull data from a spreadsheet and not navigate to the 
spreadsheet or push data into it. Links that are used to 
implement annotations will be identified by a certain 
property. This property will indicate that the link is part 
of an annotation, and that the appropriate annotation 
commands are enabled. 

A final example is a link that indicates a master-copy 
relationship. This would be used for import data. Instead 
of copying and pasting a static representation of a 
graph, the user can create a link between the original 
graph and the copy placed in the word processor docu- 
ment. 



TModelAnchorSurrogate, shown in Figure 14 as el- 
ement 1406, is the surrogate class for TModelAnchor 
1408. It provides a subset of the protocol available from 
TModelAnchor 1408. Specifically it provides protocol for 
supporting data exchange between anchors. By using 
the protocol of the surrogate, the client does not need 
to distinguish between anchors in the local document or 
a remote document. TModelAnchor 1408 maintain a list 
of attributes which describes attributes of the link such 
as what operations may be performed (e.g. push, pull). 
Attributes are managed as a simple attribute group. Pro- 
tocol is provided for adding, removing and looking up 
attributes. TModelAnchors 1 408 are owned by their cre- 
ator and it is the creator's responsibility to delete them 
unless ownership has been passed to another object 
like a TModel. Important member functions are: Cre- 
atePreferredTypeList, Choose PreferredType and Cop- 
yData. 

TModelAnchor 

TModelAnchor, shown in Figure 14 as element 
1 408, is the base class for all persistent selections which 
serve as anchors for hyperlinks. The default implemen- 
tation of TModelAnchor 1408 contains a TModelSelec- 
tion 1 1 04 to which it delegates all TModelSelection calls. 
TModelAnchor 1408 maintain a list of attributes which 
describes attributes of the link such as what operations 
may be performed (e.g. push, pull). Attributes are man- 
aged as a simple attribute group. Protocol is provided 
for adding, removing and looking up attributes. Impor- 
tant member functions are: SetSelection, Follow Exe- 



15 



20 



25 TModelAnchorSurrogate 



30 



35 



40 



45 



50 



11 



21 



EP0 728 338 B1 



22 



cute, AddAltribute, scripting, automated testing and 
AdoptLink. 

TModelLink 

The TModelLink class, shown in Figure 15 as ele- 
ment 1506, provides the representation for a link. Spe- 
cialization is accomplished by subclassing TModelAn- 
chor. There are no subclasses of TModelLink 1506. The 
"here" anchor and the "there" anchor are just names for 
the two anchors in a link. The "here" anchor in a TMod- 
elLink 1 506 is typically part of the current document and 
can be turned into a real anchor using a method of the 
TModel. The "there" anchor may be part of the current 
document or could belong to another document. TMod- 
elLinks 1506 also maintain a list of properties which de- 
scribes attributes of the link such as what operations 
may be performed (e.g. push, pull). Properties are man- 
aged as a dictionary of property names and values. Pro- 
tocol is provided for adding, removing and tooking up 
properties. Important member functions are: GetHere, 
GetThere, AddAttribute and RemoveAttribute. 

TDynamicModelAnchor 

TDynamicModelAnchor is the base class lor an- 
chors whose data specification is dynamic rather than 
static. The anchors are called "dynamic" because they 
may specify different document data each time they are 
accessed. Normal anchors always refer to the same da- 
ta in the document. For example, a dynamic anchor 
could represent the current selection in the document. 
When data was pushed from the anchor it would be the 
data represented by the current selection at that mo- 
ment. 

Document Control & Communication 

The classes in this section are included here to give 
the reader an idea how documents use the process 
model. The class TDocument is created to start a doc- 
ument in a team. It is responsible for creating the various 
frameworks and services necessary for local control of 
a document team. This includes starting servers for col- 
laboration and external document control, and providing 
control of the document filing operations. The class 
TRemoteDocument provides a remote interface to doc- 
uments in other teams, it allows data to be accessed 
from documents in other teams, and supports control of 
those documents through commands. 

Model Filing 

TDocument provides support for initiating filing op- 
erations on a document. When filing in a model, there 
is no real work to be done. TModels are filed in automat- 
ically when they are first requested from a surrogate. A 
model may be deleted from memory at any time by the 



container it desired. Of course, an exclusive lock on the 
model must be acquired to delete it, and no pointers to 
the model should be cached and held beyond the dura- 
tion of a lock on the model. Model surrogates may cache 

5 model pointers, but this will be transparent to clients. 

For filing out there is a larger role. In order to support 
a saveless model and maintain storage consistency, the 
document framework logs commands on all models in 
a store to that store. Models cannot be written individu- 

10 ally, but rather, all dirty models are always written to- 
gether. This simplifies handling of the command log, by 
allowing the entire command log to be removed from 
each store whenever models are written. The models 
are written when the document is closed, but also on a 

is periodic basis while the document is open, to reduce the 
restart time for a document in case of a system failure. 

Inter-document Communication 

20 in the document framework, each document runs in 
its own team. Documents must be able to communicate 
with one another to support many of the standard fea- 
tures of the document framework. For example hyper- 
text linking allows data to be pushed and pulled across 

2s documents, and links to be followed across documents. 
To accomplish this processing, as shown in Figure 20, 
the document framework 1700 provides a client/server 
interlace 2002 tor external documents 2004. To commu- 
nicate with an external document, a TRemoteDocument 

30 js created from a surrogate for the root model of the doc- 
ument. The TRemoteDocument object may be used to 
open, send commands, query links, etc. 

Document Startup 

35 

A new team must be created for each new docu- 
ment started. Although an "application" can be written 
which creates a document with a specific root type, this 
is not necessary. The document framework will use the 

40 capabilities provided by the runtime system in TTask- 
Program, to create and start the appropriate objects in 
the document team. A document is started by creating 
a TRemoteDocument with the surrogate for the root 
model of the document, and then making a request of 

45 the document, typically to open. This will start the doc- 
ument team and open the requested document using 
the surrogate provided. Other requests may be made of 
the document which do not require opening a user in- 
terface on the document (i.e. copying selected data from 

50 an anchor). 

TDocument 

The TDocument class acts as the controller for the 
55 document data. It creates the frameworks and servers 
necessary for a document team. It also provides control 
of the filing process. TDocument is instantiated auto- 
matically by TModelApplication when a document is 
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started. Important member functions are: SetSelection, 
GetSelection. 

TRemoteDocument 

This class provides access to a document in anoth- 
er team. This is the only way for two documents to in- 
teract for purposes of Cut/Copy, Paste, Linking, etc. be- 
cause only a single document can operate in a team. It 
allows the document to be controlled externally. Typical 
uses include, link navigation & data transfer, opening/ 
closing, etc. The following member function supports 
doing commands on remote documents (documents in 
another team): Do. 

The following member functions support data ex- 
change with anchors in remote documents: CreatePre- 
ferredTypeList, ChoosePreferredType, CopyAnchorDa- 
ta and NotifyLink. The following member functions sup- 
port opening and closing user interfaces on a remote 
document: Open, Close and IsOpen. The following 
member functions support receiving notification on 
opening and closing of documents. CreateOpenlnterest 
and CreateCloselnterest. 

Figure 21 shows the overall system design of the 
present system and method. The application layer 21 02 
interacts with the current 2106 and related 2108 docu- 
ments in storage 2104 via flow 2112. The application 
layer 21 02 also interacts with the system level document 
framework 2110 of the present invention via flow 2114, 
indicated by the circled 1 . And finally, the document 
framework 2110 of the present invention interacts with 
the current 21 06 and related 21 08 documents in storage 
2104 via flow 2116, indicated by the circled 2. 

The particulars of the document framework 2110 
have been discussed in detail above. The document 
framework 21 1 0 is a collection of objects for Anchor and 
Link Support 2118, Notification 2120, Collaboration 
2122, Embedding 2124, Data Presentation 2126, Data 
Modification 2128, Multi-Level Undo 2130, Content- 
Based Retrieval and Indexing 2132, Compound Docu- 
ment Support 2134, Data Representation 2136, Data 
Specification 2138, Model Processing 2140 and Docu- 
ment Communication 2142. As previously discussed, 
while many of the objects find particular inventiveness 
by being placed at the system level, and providing func- 
tions in conjunction with the other objects at the system 
level, it should also be understood that certain of the 
objects may also be considered at other levels of the 
system. 

StockTicker Example 

An example of a real life application may assist in 
clarifying the practical application of the subject technol- 
ogy. First, to set the stage, a review of the compound 
document technology. A model is something that holds 
data and makes it available to facilities that access, 
modily, and present the data to users. A presentation is 



a facility that provides a user with a view onto a model 
for reading and editing. A clipboard is a special model 
associated with a user's environment containing a mod- 
el that is on the clipboard in the cut/copy-paste opera- 
5 tion. 

The application implements a stock ticker which 
emulates the stock tickers found in Merrill Lynch offices 
around the country. The stock ticker presents current 
stock prices for various stocks traded on the New York 
10 Stock Exchange. It receives as input current stock pric- 
es from a database residing ultimately at the stock ex- 
change in New York City. The communication link is well 
known in the art and could for example be an asynchro- 
nous serial communication link transmitting ASCII char- 
is acters. The ASCII characters are displayed directly on 
a display using any number of fonts encoded to synchro- 
nize with ASCII 8-bit characters. The display mecha- 
nism will be referred to as a view and could be any 
number of common window or other display mecha- 
20 nismsthatarealsowellknow intheart. A clipboard mod- 
el contains a model that is a StockTicker instance. The 
StockTicker instance refers to communication and dis- 
play information ready for simulating a stock display. A 
destination model is going to receive the StockTicker in- 
25 stance in a paste operation to show how a preferred em- 
bodiment can be used to enable a compound document 
with diverse information. 

The destination model is part of a document; it could 
either be the model for the "root" model of the document 
30 or it could be an embedded model. A paste command 
is issued on the destination document. The command 
includes two specifications: 1) a reference to the source 
model on the clipboard that is to be copied, and 2) a 
specification of a location in the destination document 
35 that it should be pasted into. The paste command oper- 
ation involves the following steps. First, a type negotia- 
tion interaction between the destination model and 
source model. The source provides a list of types that it 
can provide and the destination selects a preferred type. 
40 in this case, the destination does not recognize the spe- 
cific StockTicker data type so it accepts it abstractly as 
a model and embeds it. The destination side gets a new 
copy of the StockTicker model, and it is adopted into the 
destination model. The destination model has been 
45 modified, so it sends a change notification message to 
all presentations opened on it. Each presentation re- 
ceives the notification and re-synchronizes its state with 
the new model state that includes the new StockTicker 
For instance, the presentation could be done by com- 
50 pleteiy regenerating its state from the new model state. 
A more optimized model-presentation relationship 
might involve a more special notification that tells the 
presentation precisely what changed so that the pres- 
entation can update only what changed. The outcome 
55 is that presentation queries the StockTicker model to 
generate a presentation ot itself. This is a complex op- 
eration that is detailed below. 

When the StockTicker model responds by con- 
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structing a presentation view instance, the constructor 
of this StockTicker view subclass performs the following 
steps. U creates a thread owned by the view subclass 
and starts it. The thread enters a function that performs 
the following steps. It prepares windowing and graphic 
facilities for displaying continuously updating and ani- 
mating graphics to the StockTicker presentation view. A 
specific example o1 this is a "graphics port* tacility that 
is a conduit for graphics drawn by this thread onto the 
presentation view. Then it goes into a loop which draws 
an animating presentation of the data and queries the 
stock data as needed. The properly constructed 
StockTicker presentation view is then adopted as a sub- 
view of the outer presentation, or more generally, it is 
wrapped inside an intermediate view that supports fa- 
cilities for managing embedded entity as a whole. 



Claims 

1 . An apparatus for document processing for use in a 
computer system havinga processor (1 0), a storage 
(16, 14, 20) and a display (38) under the control of 
the processor, the apparatus comprising: 

(a) a system level document framework (2110) 
stored in the storage separate from applica- 
tions, the document framework defining a plu- 
rality of model classes (2118-2142), each one 
of the plurality of model classes defining means 
for referencing data stored in the storage, 
means for creating a container object to hold a 
plurality of objects instantiated from one or 
more of the plurality of model classes and pro- 
gram logic means for processing the data and 
objects held in the container object; 

(b) means for instantiating a root model object 
from one of the plurality of model classes, the 
root model object containing a reference to data 
of a first type; 

(c) means for instantiating a plurality of addi- 
tional objects from the plurality of model class- 
es, each one of the plurality of additional model 
objects containing a reference to data of a type 
different from the first type; 

(d) means for creating a compound document 
from the root model object by adding at least 
one additional model object instantiated from 
the plurality of additional model objects to a 
container in the root model object, wherein the 
root model object and each one of the at least 
one additional model objects provide a hierar- 
chy of model objects which represent a contain- 
ership hierarchy of the compound document; 
and 



(e) means for processing the compound docu- 
ment by processing the root model object, 
which applies the processing to the at least one 
additional model object in the container in the 
5 root model object. 

2. The apparatus of claim 1 , wherein the document 
framework includes means for streaming which, in 
response to a first model, streams the first model 

io and each of a plurality of embedded models con- 
tained within the first model. 

3. The apparatus of claim 2, further comprising means 
for copying which, in response to a first one of an 

15 entire model or a selected data from a model being 
copied, copies each of a plurality of embedded 
models contained with the first one of the entire 
model or the selected data from a model. 

20 4. The apparatus of claim 3, further comprising means 
for filing a model, wherein in response to a first mod- 
el being filed, the means for filing files a plurality of 
embedded models contained within the first model 
and wherein said means for filing files each of the 

25 plurality of embedded models independently from 
the first model in which the plurality of embedded 
models are contained. 

5. The apparatus of claim 1 , wherein the document 
30 framework comprises: 

means for specifying a plurality of anchors; 
means for linking a first anchor and a second 
anchor; 

35 means for transferring information across links 

in first and second opposite directions 

wherein said transferring means includes 

40 means for initiating a transfer of information 

from either end of a link; 
means for transferring document information 
across links; and 

means for transferring commands across links. 

45 

6. The apparatus of claim 1, wherein the document 
framework includes means for stacking one or more 
commands, and means for undoing commands, 
said means for undoing commands including 

so means 1or selectively undoing commands in an or- 
der unrelated to the order in which the commands 
were stacked. 

7. The apparatus of claim 1 , wherein the document 
55 framework includes means for managing embed- 
ded models. 

8. The apparatus of claim 1 , wherein the document 
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framework includes hierarchical document support 
means for embedded data. 

9. The apparatus of claim 8, wherein the hierarchical 
document support means includes means for em- 5 
bedding data in a model. 

10. The apparatus of claim 9, wherein the means for 
embedding data in a model includes means for 
overriding protocols associated with the embedded 10 
data. 

11. The apparatus of claim 1, wherein the document 
framework includes annotation means for providing 
additional information with respect to document da- is 
ta. 

12. The apparatus of claim 1, wherein the document 
framework includes retrieval framework means for 
providing indexing and query processing. 20 

13. The apparatus of claim 12, wherein the retrieval 
framework means includes background indexing. 

14. The apparatus of claim 1, wherein the document 2s 
framework includes object surrogate means for pro- 
viding address space independent references to re- 
al objects. 

15. The apparatus of claim 1 : wherein the document 30 
framework includes means for seamlessly integrat- 
ing audio and visual information in a compound doc- 
ument. 

16. A method for document processing for use in a com- 3S 
puter system having a processor, a storage and a 
display under the control of the processor, the meth- 
od comprising the steps of: 

(a) storing a plurality of model classes in the 40 
storage, each one of the plurality of model 
classes defining referencing data stored in the 
storage; 

(b) creating a container object to hold a plurality 45 
of objects instantiated from one or more of the 
plurality of model classes; 

(c) creating logic for processing the data and 
objects held in the container object; so 

(d) instantiating a root model object from one 
of the plurality of model classes, the root model 
object containing a reference to data of a first 
type; 55 

(e) instantiating a plurality of additional model 
objects from the plurality of model classes each 



one of the plurality of additional model objects 
containing a reference to data of a type different 
from the first type; 

(f) adding at least one of the additional model 
objects to a container in the root model object 
to provide a compound document from the root 
model object: and 

(g) processing the compound document by 
processing the root model object, which applies 
the processing to the at least one additional 
model object in the container in the root model 
object. 

17. The method of claim 16, including the step of 
streaming a first model and each of a plurality of 
embedded models contained within the first model. 

18. The method of claim 16, including the step of cop- 
ying a model and each of a plurality of embedded 
models contained with the model. 

19. The method of claim 16, including the step of filing 
a first model, wherein in response to the first model 
being filed, the step of filing a first model includes 
the steps of: 

filing a plurality of embedded models contained 
within the first model and 

filing each of the plurality of embedded models 
independently from the first model in which the 
plurality of embedded models are contained. 

20. The method of claim 16, including the step of estab- 
lishing at least one link between a first anchor and 
a second anchor; initiating a transfer of information 
from either end of at least one link; transferring in- 
formation across the at least one link in a first direc- 
tion; initiating a transfer of information from a sec- 
ond different end of the at least one link and trans- 
ferring information across the at least one link in a 
second opposite direction. 

21. The method of claim 16, including the steps of 
stacking one or more commands, and selectively 
undoing commands in an order unrelated to the or- 
der in which the commands were requested. 

22. The method of claim 16 : including the step of man- 
aging embedded models. 

23. The method of claim 16, including the step of sup- 
porting hierarchical document data including em- 
bedded data. 

24. The method of claim 23 : including the step of em- 
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bedding data in a model. 

25. The method of claim 24, including the step of over- 
riding protocols associated with the embedded da- 
ta. 

26. The method of claim 16, including the step ol anno- 
tating for providing additional information with re- 
spect to document data. 

27. The method of claim 1 6, including the step of index- 
ing and query processing using a retrieval frame- 
work. 

28. The method of claim 27, including the step of back- 
ground indexing. 

29. The method of claim 16, including the step of pro- 
viding address space independent references to re- 
al objects using surrogate objects. 

30. The method of claim 1 6, including the step of seam- 
lessly integrating audio and visual information into 
a compound document. 



Patentanspruche 

1. Eine Einrichtung fur die Dokumentenverarbeitung 
zur Benutzung in einem Computersystem, das ei- 
nen Prozessor (1 0), einen Speicher (1 6, 1 4, 20) und 
eine von dem Prozessor gesteuerte Anzeigevor- 
richtung (38) aufweist, die Einrichtung umfalM: 

(a) ein Dokumenten-Rahmenwerk (2110) auf 
Systemebene, das in dem Speicher separat 
von Anwendungen gespeichert ist, das Doku- 
menten-Rahmenwerk definiert eine Vielzahl 
von Modellklassen (2118-2142), von denen je- 
de Mittel zur Adressierung von im Speicher ge- 
speicherten Daten definiert, Mittel zum Erzeu- 
gen eines Behalterobjekts zur Aufnahme einer 
Vielzahl von Objekten, die von einer oder meh- 
reren der Vielzahl von Modellklassen instanti- 
iert worden sind : und Programmlogik-Mittel zur 
Verarbeitungder Daten undObjekte, die im Be- 
halterobjekt gehalten werden; 

(b) Mittel zum Instantiieren eines Wurzel-Mo- 
dellobjekts von einer der Vielzahl von Modell- 
klassen, das Wurzel-Modellobjekt enthalt eine 
Referenz zu Daten eines ersten Typs; 

(c) Mittel zum Instantiieren einer Vielzahl von 
zusatzlichen Objekten aus der Vielzahl von Mo- 
dellklassen, jedes der Vielzahl von zusatzli- 
chen Modellobjekten enthalt eine Relerenz zu 
Daten eines Typs, der sich vom ersten Typ un- 
terscheidet; 

(d) Mittel zum Erzeugen eines zusammenge- 



setzten Dokuments aus dem Wurzel-Modellob- 
jekt durch Hinzufugung von wenigstens einem 
zusatzlichen Modellobjekt, das aus der Vielzahl 
von zusatzlichen Objekten instantiiert worden 

s ist, zu einem Behalter im Wurzel-Modellobjekt, 

wobei das Wurzel-Modellobjekt und jedes von 
dem wenigstens einem zusatzlichen Modellob- 
jekt eine Hierarchie von Modellobjekten bildet, 
die eine Behalter-Hierarchie des zusammen- 

10 gesetzten Dokuments darstellt, und 

(e) Miltel zum Verarbeiten des zusammenge- 
setzten Dokuments durch Verarbeiten des 
Wurzel-Modellobjekts, das die Verarbeitung 
auf das wenigstens eine zusatzliche Modellob- 

15 jekt im Behalter des Wurzel-Modellobjekts an- 

wendet. 

2. Die Einrichtung nach Anspruch 1, worin das Doku- 
menten-Rahmenwerk Mittel enthalt zum Daten-St- 
20 reaming, die in Beantwortung eines ersten Modells 
ein Streaming des ersten Modells und eines jeden 
einer Vielzahl von im ersten Model eingebetteten 
Modellen durchfuhren. 

25 3. Die Einrichtung nach Anspruch 2, weiterenthaltend 
Mittel zum Kopieren, die in Beantwortung eines er- 
sten von einem ganzen Modell oder von ausge- 
wahlten Daten eines Modells, das kopiert wird, je- 
des einer Vielzahl von eingebetteten Modellen, die 

30 in dem ersten von dem ganzen Modell enthalten 
sind, oder ausgewahlte Daten eines Modells kopie- 
ren. 

4. Die Einrichtung nach Anspruch 3, weiter enthaltend 
35 Mittel zum Ablegen eines Modells, worin als Ant- 
wort auf ein erstes Modell, das abgelegt wird, die 
Mittel zum Ablegen eine Vielzahl von eingebetteten 
Modellen ablegen, die in dem ersten Modell enthal- 
ten sind, und worin besagte Mittel zum Ablegen ein 

40 jedes der Vielzahl von eingebetteten Modellen un- 
abhangig vom ersten Modell ablegen, in dem die 
Vielzahl von eingebetteten Modellen enthalten ist. 

5. Die Einrichtung nach Anspruch 1, worin das Doku- 
45 menten-Rahmenwerk enthalt: 

Mittel zur Spezifizierung einer Vielzahl von An- 
kern; Mittel zum Verbinden eines ersten Ankers 
mit einem zweiten Anker; 
50 Mittel zum Ubertragen von Informationen Ober 

Verbindungen in ersten Richtungen und entge- 
gengesetzten zweiten Richtungen, 

worin besagte Ubertragungsmittel enthalten 

55 

Mittel zum Initiieren einer Ubertragung von In- 
formationen von beiden Enden einer Verbin- 
dung; 
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Mittel zum Ubertragen von Dokument-lnforma- 
tionen Ober Verbindungen; und 
Mittel zum Ubertragen von Befehlen Ober Ver- 
bindungen. 

6. Die Einrichtung nach Anspruch 1 , worin das Doku- 
menten-Rahmenwerk Mittel zum Stapeln eines 
oder mehrerer Befehle enthalt sowie Mittel zum 
Ruckgangigmachen von Befehlen, besagte Mittel 
zum Ruckgangigmachen von Befehlen enthalten 
Mittel zum selektiven Ruckgangigmachen von Be- 
fehlen in einer Ordnung, die nicht in Beziehung 
stent zu der Ordnung, in der die Befehle gestapelt 
wurden. 

7. Die Einrichtung nach Anspruch 1 , worin das Doku- 
menten-Rahmenwerk Mittel enthalt zum Verwalten 
eingebetteter Modelle. 

8. Die Einrichtung nach Anspruch 1 , worin das Doku- 
menten-Rahmenwerk hierarchische Dokument- 
Unterstutzungsmittel fur eingebettete Daten ent- 
halt. 

9. Die Einrichtung nach Anspruch 8, worin die hierar- 
chischen Dokument-Unterstutzungsmittel Mittel 
enthalten zum Einbetten von Daten in ein Modell. 

10. Die Einrichtung nach Anspruch 9, worin die Mittel 
zum Einbetten von Daten in ein Modell Mittel zum 
Ubersteuern von Protokollen enthalten, die mit den 
eingebetteten Daten verbunden sind. 

11. Die Einrichtung nach Anspruch 1 , worin das Doku- 
menten-Rahmenwerk Beschriftungsmittel enthalt 
zur Bereitstellung zusatzlicher Informationen in Be- 
zug auf die Dokumentdaten. 

12. Die Einrichtung nach Anspruch 1 , worin das Doku- 
menten-Rahmenwerk Wiederauffinden-Rahmen- 
werk-Mittel enthalt zur Bereitstellung einer Index- 
und Abfrageverarbeitung. 

13. Die Einrichtung nach Anspruch 12, worin die Wie- 
derauffinden-Rahmenwerk-Mittel Mittel enthalten 
zur Hintergrund-lndexierung. 

14. Die Einrichtung nach Anspruch 1, worin das Doku- 
menten-Rahmenwerk Objekt-Ersatzmittel enthalt 
zur Bereitstellung von Adressraum unabhangig von 
Referenzen zu realen Objekten. 

15. Die Einrichtung nach Anspruch 1 , worin das Doku- 
menten-Rahmenwerk Mittel enthalt zur nahtlosen 
Integration von Audioinformationen und visuellen 
Informationen in ein zusammengesetztes Doku- 
ment. 



16. Ein Verfahren fur die Dokumentenverarbeitung zur 
Benutzung in einem Computersystem, das einen 
Prozessor, einen Speicher und eine von dem Pro- 
zessor gesteuerte Anzeigevorrichtung aufweist, 

5 das Verfahren enthalt die Schritte: 

(a) Speicherung eine Vielzahi von Modellklas- 
sen in dem Speicher, jeder der Vielzahi von Mo- 
dellklassen definiert die Adressierung von im 

10 Speicher gespeicherten Daten; 

(b) Erzeugen eines Behalterobjekts zur Auf- 
nahme einer Vielzahi von Objekten, die von ei- 
nem oder mehreren der Vielzahi von Modell- 

15 klassen instantiiert worden sind; 

(c) Erzeugen von Programmlogik zur Verarbei- 
tung der Daten und Objekte, die im Behalterob- 
jekt gehalten werden; 

20 

(d) Instantiieren eines Wurzel-Modellobjekts 
von einer der Vielzahi von Modellklassen, das 
Wurzel-Modellobjekt enthalt eine Referenz zu 
Daten eines ersten Typs; 

25 

(e) Instantiieren einer Vielzahi von zusatzlichen 
Objekten aus der Vielzahi von Modellklassen, 
jedes der Vielzahi von zusatzlichen Modellob- 
jekten enthalt eine Referenz zu Daten eines 

30 Typs, der sich vom ersten Typ unterscheidet: 

(d) HinzufOgen von wenigstens einem zusatz- 
lichen Modeltobjekt zu einem Behalter im Wur- 
zel-Modellobjekt zur Bereitstellung eines zu- 

35 sammengesetzten Dokuments aus dem Wur- 

zel-Modellobjekt; und 

(e) Verarbeiten des zusammengesetzten Do- 
kuments durch Verarbeiten des Wurzel-Modell- 

40 objekts, das die Verarbeitung auf das wenig- 

stens eine zusatzliche Modellobjekt im Behal- 
ter des Wurzel-Modellobjekts anwendet. 

17. Das Verfahren nach Anspruch 16, enthaltend den 
45 Schritt des Streaming eines ersten Modells und ei- 
nes jeden einer Vielzahi von im ersten Model ein- 
gebetteten Modellen. 

18. Das Verfahren nach Anspruch 16, enthaltend den 
50 Schritt des Kopierens eines Modells und eines je- 
den einer Vielzahi von eingebetteten Modellen, die 
in dem Modell enthalten sind. 

19. Das Verfahren nach Anspruch 16, enthaltend den 
55 Schritt des Ablegens eines ersten Modells, worin 

als Antwort auf das erste Modell, das abgelegt wird, 
der Schritt zum Ablegen eines ersten Modells die 
Schritte enthalt: 
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17. 

45 



18. 

50 



19. 

55 
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Ablegen einer Vielzahl von eingebetteten Mo- 
deller), die in dem ersten Modell enthalten sind, 
und 

Ablegen eines jeden der Vielzahl von eingebet- 
teten Modellen unabhangig vom ersten Modell, s 
in dem die Vielzahl von eingebetteten Modellen 
enthalten ist. 

20. Das Verfahren nach Anspruch 16, enthaltend den 
Schritt der Herstellung wenigstens einer Verbin- io 
dung zwischen einem ersten Anker und einem 
zweiten Anker; Initiieren einer Ubertragung von In- 
formationen von beiden Enden von wenigstens ei- 
ner Verbindung; Ubertragen von Informationen von 
beiden Enden wenigstens einer Verbindung in einer is 
ersten Richtung; Initiieren einer Ubertragung von 
Informationen von einem zweiten unterschiedli- 
chen Ende der wenigstens einen Verbindung und 
Ubertragen von Informationen uber die wenigstens 
eine Verbindung in einer zweiten Richtung. 20 

21. Das Verfahren nach Anspruch 16, enthaltend die 
Schritte des Stapelns eines oder mehrerer Befehle 
und des selektiven ROckgangigmachens von Be- 
fehlen in einer Ordnung, die nicht in Beziehung 2s 
steht zu der Ordnung, in der die Befehle angefordert 
wurden. 

22. Das Verfahren nach Anspruch 16, enthaltend den 
Schritt des Verwaltens eingebetteter Modelle. 30 

23. Das Verfahren nach Anspruch 16, enthaltend den 
Schritt der Unterstutzung hierarchischer Doku- 
ment-Daten, die eingebettete Daten enthalten. 

35 

24. Das Verfahren nach Anspruch 23, enthaltend den 
Schritt des Einbettens von Daten in ein Modell. 

25. Das Verfahren nach Anspruch 24, enthaltend den 
Schritt des Ubersteuerns von Protokollen, die mit 40 
den eingebetteten Daten verbunden sind. 

26. Das Verfahren nach Anspruch 16, enthaltend den 
Schritt des Beschriftens zur Bereitstellung zusatzli- 
cher Informationen in Bezug auf die Dokumentda- 45 
ten. 

27. Das Verfahren nach Anspruch 16, enthaltend den 
Schritt des Indexierens und der Abfrageverarbei- 
tung unter Benutzung eines Wiederauffinden-Rah- so 
menwerks. 

28. Das Verfahren nach Anspruch 27, enthaltend den 
Schritt der Hintergrund-lndexierung. 

55 

29. Das Verfahren nach Anspruch 16, enthaltend den 
Schritt der Bereitstellung von Adressraum unab- 
hangig von Referenzen zu realen Objekten unter 



Benutzung von Ersatzobjekten. 

30. Das Verfahren nach Anspruch 16, enthaltend den 
Schritt der nahtlosen Integration von Audioinforma- 
tionen und visuellen Informationen in ein zusam- 
mengesetztes Dokument. 



Revendicatlons 

1. Appareil de traitement de documents pour utilisa- 
tion dans un systeme d'ordinateur ayant un proces- 
ses (10), une memoire (16, 14, 20) et un dispositif 
d'affichage (38) sous le controle du processeur, 
Pappareil comprenant : 

a) un programme d'exploitation de documents 
de niveau systeme (2110) emmagasinedans la 
memoire et separe des applications, le pro- 
gramme d'application de documents definis- 
sant une pluralite de classes de modeles (211 8, 
2142), chacune de la pluralite de classes de 
modeles definissant des moyens pour referen- 
cer des donnees emmagasinees en memoire, 
des moyens pour creer un objet conteneur de 
facon h maintenir une pluralite d'objets concre- 
tises a partir d'une ou plusieurs de la pluralite 
de classes de modeles et des moyens logiques 
de programme pour traiter les donnees et les 
objets maintenus dans I'objet conteneur, 

b) des moyens pour concretiser un objet mode- 
le racine a partir d'un de la pluralite de classes 
de modeles, I'objet modele racine contenant 
une reference aux donnees d'un premier type, 

c) des moyens pour concretiser une pluralite 
d'objets modeles additionnels a partir de la plu- 
ralite de classes de modeles, chacun des ob- 
jets modeles additionnels contenant une refe- 
rence a des donnees d'un type different du pre- 
mier type, 

d) des moyens pour creer un document com- 
pose a partir de I'objet modele racine en addi- 
tionnant au moins un objet modele additionnel 
concretise a partir de la pluralite d'objets mo- 
deles additionnels a un conteneur dans I'objet 
modele racine, dans lesquels I'objet modele ra- 
cine et chacun des objets modeles additionnels 
fournit une hierarchie d'objets modeles qui re- 
presente une hierarchie de contenu du docu- 
ment compose, et 

e) des moyens pour traiter le document com- 
pose en traitant I'objet modele racine, et qui ap- 
pliquent le traitement audit objet modele addi- 
tionnel dans le conteneur de I'objet modele ra- 
cine. 

2. Appareil selon la revendication 1, dans lequel le 
programme d'application de documents comprend 
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des moyens de transmission qui, en reponse a un 
premier modele, transmettent le premier modele et 
chacun de la pluralite des modeles incorpores con- 
tenus dans le premier modele. 

5 

3. Appareil selon le revendication 2, comprenant en 
outre des moyens de copie qui, en reponse a un 
premier modele entier ou a des donnees selection- 
nees a partir d'un modele en train d'etre copie, co- 
pient chacun d'une pluralite de modeles incorpores 10 
contenus dans le premier parmi le modele entier ou 

les donnees selectionnees a partir d'un modele. 

4. Appareil selon la revendication 3, comprenant en 
outre des moyens pour deposer un modele, dans is 
lequel, en reponse a un premier modele etant de- 
pose, les moyens pour d^poser deposent une plu- 
ralite de modeles incorpores contenus dans le pre- 
mier modele et dans lequel lesdits moyens pour de- 
poser deposent chacun de la pluralite de modeles 20 
incorpores independamment du premier modele 
dans lequel la pluralite de modeles incorpores sont 
contenus. 



programme d'application de documents comprend 
des moyens pour gerer les modeles incorpores. 

8. Appareil selon la revendication 1, dans lequel le 
programme d'application de documents comprend 
des moyens de support de documents hierarchi- 
ques pour des donnees incorporees. 

9. Appareil selon la revendication 8 S dans lequel les 
moyens de support de documents hierarchiques 
comprennent des moyens pour incorporer des don- 
nees dans un modele. 

10. Appareil selon la revendication 9, dans lequel les 
moyens pour incorporer des donnees dans un mo- 
dele comprennent des moyens pour passer outre 
aux protocoles associes aux donnees incorporees. 

11. Appareil selon la revendication 1, dans lequel le 
programme d'application de documents comprend 
des moyens d'annotation pour fournir des informa- 
tions additionnelles par rapport aux donnees de do- 
cument. 



5. Appareil selon la revendication 1, dans lequel le 2S 
programme d'application de documents 
comprend : 

des moyens pour specifier une pluralite d'an- 
cres : 30 
des moyens pour lier une premiere ancre et une 
seconde ancre, 

des moyens pour transferer des informations 
au travers des liaisons dans un premier et un 
second sens oppose, 35 

dans lequel lesdits moyens pour transferer 
comprennent : 

des moyens pour initialiser un transfert d'infor- 40 
mations a partir d'une extr6mite ou I'autre de la 
liaison, 

des moyens pour transferer des informations 
de document au travers des liaisons, et 
des moyens pour transferer des commandes 
au travers des liaisons. 

6. appareil selon la revendication 1 , dans lequel le pro- 
gramme d'application de documents comprend des 
moyens pour mettre en pile une ou plusieurs com- so 
mandes, et des moyens pour annuler des comman- 
des, lesdits moyens pour annuler des commandes 
comprenant des moyens pour annuler selective- 
ment des commandes dans un ordre sans relation 
avec I'ordre dans lequel les commandes ont ete mi- ss 
ses en pile. 

7. Appareil selon la revendication 1, dans lequel le 



12. Appareil selon la revendication 1, dans lequel le 
programme d'application de documents comprend 
des moyens de recherche fournissant le traitement 
des requetes et de indexation. 

13. Appareil selon la revendication 12, dans lequel les 
moyens de recherche comprennent I'indexation 
d'arriere plan. 

14. Appareil selon la revendication 1, dans lequel le 
programme d'application de documents comprend 
des moyens de remplacement d'objet pour fournir 
des references independantes d'espace d'adres- 
ses aux objets reels. 

15. Appareil selon la revendication t, dans lequel le 
programme d'application de documents comprend 
des moyens pour integrer sans probleme des infor- 
mations audio et visuelles dans un document com- 
pose. 

16. Methode de traitement de documents pour utilisa- 
tion dans un systeme d'ordinateur ayant un proces- 
seur, une memoire et un dispositif d'affichage sous 
le controle du processeur, la methode comprenant 
les etapes de: 

a) emmagasiner une pluralite de classes de 
modeles dans la memoire, chacune de la plu- 
ralite de classes de modeles definissant des 
donnees de referencer emmagasinees en me- 
moire, 

b) creer un objet conteneur de facon a mainte- 
nir une pluralite d'objets concretises a partir 
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d'une ou plusieurs de la pluralite de classes de 
modeles, 

c) creer de la logique pour traiter les donnees 
et les objets malntenus dans I'objet conteneur, 

d) concretiser un objet modele racine a partir 
d'un de la pluralite de classes de modeles, I'ob- 
jet modele racine contenant une reference aux 
donnees d'un premier type, 

e) concretiser une pluralite d'objets modeles 
additionnels a partir de la plurality de classes 
de modeles, chacun des objets modeles addi- 
tionnels contenant une reference a des don- 
nees d'un type different du premier type, 

f) additionner au moins un des objets modeles 
additionnels a un conteneurdans I'objet mode- 
le racine pour foumir un document compose a 
partir de I'objet modele racine, et 

g) traiter le document compose en traitant I'ob- 
jet modele racine, ce qui applique le traitement 
audit objet modele additionnel dans le conte- 
neur de I'objet modele racine. 

17. Methode selon la revendication 16, comprenant 
I'etape de transmettre un premier modele et chacun 
d'une pluralite de modeles incorpores contenus 
dans le premier modele. 

18. Methode selon la revendication 16, comprenant 
l'6tape de copier un modele et chacun d'une plura- 
lite de modeles incorpores contenus dans le mode- 
le. 

19. Methode selon la revendication 16, comprenant 
I'etape de deposer un premier modele, dans laquel- 
le, en r6ponse au premier modele etant depose, 
I'etape de deposer un premier modele comprend 
les etapes de : 



des, et annuler selectivement des commandes 
dans un ordre sans relation avec I'ordre dans lequel 
les commandes ont ete mises en pile. 

5 22. Methode selon la revendication 16, comprenant 
I'etape de gerer les modeles incorpores. 

23. Methode selon la revendication 16, comprenant 
I'etape de supporter des donnees de documents 

io hierarchiques incluant des donnees incorporees. 

24. Methode selon la revendication 23, comprenant 
I'etape d'incorporer des donnees dans un modele. 

15 25. Methode selon ia revendication 24, comprenant 
I'etape de passer outre aux protocoles associes aux 
donnees incorporees. 

26. Methode selon la revendication 16, comprenant 
20 I'etape d'annoter pour foumir des informations ad- 

ditionnelles par rapport aux donnees de document. 

27. Methode selon la revendication 16, comprenant 
I'etape d'indexation et de traitement des requetes 

25 en utilisant un programme de recherche. 

28. Methode selon la revendication 27, comprenant 
I'etape d'indexation d'arriere plan. 

30 29. Methode selon la revendication 16, comprenant 
I'etape de fournir des references independantes 
d'espace d'adresses aux objets reels en utilisant 
des objets de remplacement. 

35 30. Methode selon la revendication 16, comprenant 
I'etape d'integrer sans probleme des informations 
audio et visuelles dans un document compose. 



deposer une pluralite de modeles incorpores 
contenus dans le premier modele, et 40 
deposer chacun de la pluralite de modeles in- 
corpores independamment du premier modele 
dans lequel la pluralite de modeles incorpores 
sont contenus. 

45 

20. Methode selon la revendication 16, comprenant 
I'etape d'etablirau moins un lien entre une premiere 
ancre et une seconde ancre, initialiser un transfer! 
d'informations a partir d'une extremite ou I'autre 
d'au moins une liaison, transferer des informations so 
par une extremite ou I'autre d'au moins une liaison 
dans un premier sens, initialiser un transfert d'infor- 
mations a partir d'une autre extremite de ladite 
liaison et transferer des informations par ladite 
liaison dans un second sens oppose 55 

21 . Methode selon la revendication 1 6, comprenant les 
etapes de mettre en pile une ou plusieurs comman- 
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